home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 000314_timbl@www3.cern.ch _Thu Nov 12 18:39:38 1992.msg < prev    next >
Internet Message Format  |  1994-01-24  |  4KB
  1. Return-Path: <timbl@www3.cern.ch>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA07238; Thu, 12 Nov 92 18:39:38 MET
  4. Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
  5.     id AA14070; Thu, 12 Nov 92 18:52:26 +0100
  6. Received: by www3.cern.ch (NX5.67c/NX3.0S)
  7.     id AA00296; Thu, 12 Nov 92 18:48:05 +0100
  8. Date: Thu, 12 Nov 92 18:48:05 +0100
  9. From: Tim Berners-Lee <timbl@www3.cern.ch>
  10. Message-Id: <9211121748.AA00296@www3.cern.ch>
  11. Received: by NeXT.Mailer (1.87.1)
  12. Received: by NeXT Mailer (1.87.1)
  13. To: Dan Connolly <connolly@pixel.convex.com>
  14. Subject: Re: indexes as links rather than documents
  15. Cc: www-talk@nxoc01.cern.ch
  16. Reply-To: timbl@nxoc01.cern.ch
  17.  
  18.  
  19. > Date: Tue, 10 Nov 92 19:23:12 CST
  20. > From: Dan Connolly <connolly@pixel.convex.com>
  21. > 
  22.  
  23. > I keep running across interesting bits of evidence that tell me that
  24. > indexes should be a type of link rather than a type of document.
  25. > 
  26.  
  27. > <dd><a HREF="wais://quake.think.com/INFO" INDEX=1>search</a>
  28. > <a HREF="wais://quake.think.com/directory-of-servers.src">describe</a>
  29. > 
  30.  
  31.  
  32. Dan,
  33.  
  34. If you found that most index documents are empty, then that was probably
  35. because you were in gopherspace -- in waisspace they all have descriptions.
  36.  
  37. [[even though as Ed points out the description lives in one place and the index  
  38. in another so it is dificult to know which address to use! On that point,
  39. ed, I chose to refer to the index as that is what actually MUST be available,
  40. when the source file is not essential, it is just icing on the cake]].
  41.  
  42. How about above instead of
  43.  
  44. > <dd><a HREF="wais://quake.think.com/INFO" INDEX=1>search</a>
  45.  
  46. using
  47.  
  48. > <dd><a HREF="wais://quake.think.com/INFO" RELATIONSHIP=SEARCHME>search</a>
  49.  
  50. This expresses that the type of relationship between the documents is
  51. that when you follow the link you should search the seocnd index. 
  52.  
  53.  
  54. An important addition is just a document-wide
  55. <LINK HREF="wais://quake.think.com/INFO" RELATIONSHIP=SEARCHME>
  56. empty element which makes a document searchable, directing seraches
  57. to a given index. Similarly  RELATIONSHIP=GLOSSARY would
  58. allow double-clicked words to be looked up in a remote glossary.
  59.  
  60. This would solve the problem with WAIS source files, in that their hypertext
  61. representation would have such a link to the index, so the source file itself
  62. appears searchable. There are lots of places where this would be neat.
  63.  
  64. We have been over this a little before.  Perhaps we should allow either
  65. option, as it is so checken-and-egg as a problem.
  66.  
  67. The argument for the W3 model is that often the user will want to search
  68. or not search a single index, and he doesn't want two operations: one to
  69. select the fact that he wants to search (click) and one to search
  70. (typetypetyepe return).  He just wants one.   After all,
  71. if he clicks on a gopher index link, what does he get? a serach panel.
  72. And what is the difference between that and a serachable document?
  73. Only speed of display. If the serachable document can come up as fast as
  74. a search panel, then there is no contest. If not, there is.
  75.  
  76. In the long term the search will become (if my philosophising of
  77. the oher day comes true) an instance of a class of search query, for which
  78. an editor will exist if the client supports it. So searches with
  79. toggle buttons and radio buttons and stuff will be possible,
  80. and a gopher serach and W3 search will be subclasses.
  81.  
  82. I feel that we are talking about optimising speed when the net is slow
  83. here. In general, I don't want to talk about a dictionary (search[1].
  84. describe[2]) I want to talk about a dictionary[3]. The former seems kinda
  85. messy. It just saves time given a slow network now...
  86.  
  87. Tim
  88.